Guideline: Unit Test And Unit Integration Test

Unit Test

In unit testing, it is important to realise what the place of testing is within development. The unit testers are usually the developers, who test their own unit. The development project leader, a separate test coordinator or the application integrator described in Roles Not Described As A Position coordinate the tests.

A point to note is the specifying of test cases. Developers do not always see the usefulness of this. By opting where possible for ‘light’ test design techniques and elementary forms of test documentation in particular, the degree of acceptance is considerably increased. Particularly with manual unit tests, considerable powers of persuasion are necessary to convince the developers that the writing out of test cases in those specific instances offers advantages over the unprepared execution of the tests.

A good example that shows the advantage of test design techniques and the specifying of test cases is the testing of a multiple condition (IF A=1 and B=2 and C=3 THEN …). With the aid of the test design technique of Elementary Comparison, it is relatively simple to derive a limited set of test cases (4 in this example) that provide a high degree of test coverage. Devising test cases without a technique here quickly leads to either too meagre test coverage or a multiple of test cases (23 = 8 in this example).

More and more development environments are now making it possible to include the (automated) test code in the (source) code. The unit test then consists of starting the test code, which subsequently executes (a part of) the source code. Such unit tests are grouped into a ‘test harness’.

The writing of unit tests in a test harness is an extra effort that should not be ignored. Experience teaches that the developing of test code costs 10%-30% extra effort [Vaaraniemi, 2003].

Development methods have firmly embraced the possibility of including test code directly with the (source) code. Initiatives like Test Driven Development (see Quality Measures) make testing an increasingly important part of system development.

Unit Integration Test

When a unit has been tested and approved, it can be integrated with other units into a working (part of the) system. Rarely are all the units combined and tested at one time – the so-called “big bang” scenario. The disadvantage of this late integration is that, in general, many defects are found, and tracing the causes takes up a lot of time. A more effective method is integrating numbers of units together in steps and testing after each integration step. In this way, defects are found at an early stage, when the cause is still relatively easy to detect. Unit integration testing thus plays a role particularly in repeatedly demonstrating that the new or amended unit(s) continue to work well in conjunction with earlier integrated units.

The best sequence of integration and the number of integration steps required depends on the location of the most risk-related parts of the system. Ideally, the integration starts with those units in which the most problems are expected. This prevents serious problems arising at the end of the unit integration test.

Executing unit integration tests requires extensive knowledge of the content, structure and especially the information exchange of underlying units. This in-depth knowledge means that often a separate role is allocated to the integration of units: the application integrator (see Quality Measures).

The developments in the area of development environments also facilitate automated compilation, integration and testing. This takes place with the aid of ‘build & deploy’ scripts. ‘Build’ in this context is the combining of the various software components into a software package that can be exported to a particular environment. ‘Deploy’ is the rolling out of the software in the target environment, in other words the conversion of the software package into the operational (installed) form. Scripts make it possible to execute build & deploy by automation. Within the build & deploy scripts, the test harness is called up. In this, besides the automated unit tests, tests are also built and executed that exceed the boundaries of the units and the integration tests. Integration test cases often form a functional path from beginning to end through the application. By making use of stubs and drivers (see Types Of Test Tools) tests can be included at an early stage that run through the application from beginning to end. As with automated execution of unit tests, this possibility of automatic integrating and testing has found its way into the development methods. Rather than seeing the integration (test) as mainly a concluding activity, the Continuous Integration method (see Quality Measures) has been introduced, which brings to the fore as much as possible any problems in connection with the combining of units.